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Abstract 


The framework for Operations, 
within the MPLS Transport Profile 
Maintenance Entity Group Intermediate Points 


(MIPs) 


Administration and Maintenance (OAM) 
(MPLS-TP) describes how the 


(MIPS) may be situated 


within network nodes at incoming and outgoing interfaces. 


This document elaborates on important considerations for internal MIP 


addressing. More precisely, 


it describes important restrictions for 


any mechanism that specifies a way of forming OAM messages so that 
they can be targeted at MIPs on either incoming or outgoing 
interfaces and forwarded correctly through the forwarding engine. 


Furthermore, 


the document includes considerations for node 


implementations where there is no distinction between the incoming 


and outgoing MIP. 


Status of This Memo 


This document is not an Internet Standards Track specification; 


it is 


published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). 


It represents the consensus of the IETF community. 


It has 


received public review and has been approved for publication by the 


Internet Engineering Steering Group 


(IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 


Standard; 


Information about the current status of this document, 


see Section 2 of RFC 5741. 


any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7054. 
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1. Introduction 


The framework for Operations, Administration and Maintenance (OAM) 
within the MPLS Transport Profile (MPLS-TP) (the MPLS-TP OAM 
Framework, [RFC6371]) distinguishes two configurations for the 
Maintenance Entity Group Intermediate Points (MIPs) on a node. It 
defines per-node MIPs and per-interface MIPs, where a per-node MIP is 
a single MIP per node in an unspecified location within the node and 
per-interface MIPs are two (or more) MIPs per node on each side of 
the forwarding engine. 


In-band OAM messages are sent using the Generic Associated Channel 
(G-ACh) [RFC5586]. OAM messages for the transit points of 
pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using 
the expiration of the MPLS shim header Time-to-Live (TTL) field. OAM 
messages for the end points of PWs and LSPs are simply delivered as 
normal. 
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OAM messages delivered to end points or transit points are 
distinguished from other (data) packets so that they can be processed 
as OAM. In LSPs, the mechanism used is the presence of the Generic 
Associated Channel Label (GAL) in the Label Stack Entry (LSE) under 
the top LSE [RFC5586]. In PWs, the mechanism used is the presence of 
the PW Associated Channel Header (PWACH) [RFC4385] or the presence of 
a GAL [RFC6423]. 


If multiple MIPs are present on a single node, these mechanisms alone 
provide no way to address one particular MIP out of the set of MIPs. 
A mechanism that addresses this shortcoming has to obey a few 
important design considerations, which are discussed in this 
document. 


2. Terminology 


In this document, we use the term in-MIP (incoming MIP) to refer to 
the MIP that processes OAM messages before they pass through the 
forwarding engine of a node. An out-MIP (outgoing MIP) processes OAM 
messages after they have passed the forwarding engine of the node. 
The two together are referred to as internal MIPs. The term 
"forwarding engine" is used as defined in [RFC6371]. 


Note that the acronym "OAM" is used in conformance with [RFC6291]. 
3. Summary of the Problem Statement 


Figure 1 shows an abstract functional representation of an MPLS-TP 
node. It is decomposed as an incoming interface (labeled "In"), a 
forwarding engine (FW), and an outgoing interface (labeled "Out"). 

As per the discussion in [RFC6371], MIPs may be placed in each of the 
functional interface components. 


| MIP | | MIP | 
} | os 

----- >-| In |->-| FW |->-| Out |->---- 
| i/£ | ---- | i/£ | 


Figure 1: Abstract Functional Representation of an MPLS-TP Node 
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Several distinct OAM functions are required within this architectural 
model for both PWs and LSPs, such as: 


o Connectivity Verification (CV) between a Maintenance Entity Group 
End Point (MEP) and a MIP 


o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing 
MIPs 


o data-plane loopback configuration at a MIP 
o diagnostic tests 


The MIPs in these OAM functions may also be the MIPs at the incoming 
or outgoing interfaces. 


Per-interface MIPs have the advantage that they enable a more 
accurate localization and identification of faults and diagnostic 
tests. In particular, the identification of whether a problem is 
located between nodes or on a particular node and where on that node 
is greatly enhanced. For obvious reasons, it is important to narrow 
down the cause of a fault quickly to initiate a timely and well- 
directed maintenance action to resume normal network operation. 


The following two figures illustrate the fundamental difference 
between using per-node and per-interface MEPs and MIPs for OAM. 
Figure 2 depicts OAM using per-node MIPs and MEPs. For reasons of 
exposition, we pick a location for the MIPs on the nodes but the 
standard does not mandate the exact location for the per-node model. 
In the figure, a bidirectional LSP is depicted where in the forward 
(FWD) direction MEP1, MIP1, and MEP2 are located on the ingress 
interface. In the backward (BWD) direction MEP1’, MIP1’ and MEP2’ 
are located on the egress interface, i.e., the same interfaces. S1 
in the figure denotes the segment from PE1 In to P1 In and S2 denotes 
the segment from PE1 In to P2 In. Figure 3, on the other hand, shows 
the same basic network, but per-interface maintenance points are 
configured for OAM operations. Note that these figures are merely 
examples. It is important to note that per-interface MEPs or per- 
interface MIPs must logically be placed at a point before (for 
in-MIP) or after (for out-MIP) passing the forwarding engine as 
defined in [RFC6371]. All traffic associated with the MEP/MIP must 
pass through or be terminated at that point. 
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Customer | Operator’s Administrative | Customer 
Domain | Domain | Domain 
------ > |<--------------------------------------->| <------ 
CE1 T-PE/PE1 S-PE/P1 T-PE/PE2 CE2 
| <-------- > <-------- > <-------- > | 
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 
M e d E TO AT oi a 
E eda Pons ai AE A a E T A A 
+---+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +---+ 
In FW Out In FW Out In FW Out | 
FWD PW/LSP | o0-------------------------- > | 
| V------------- *------------- v 
| MEP1 MIP1 MEP2 
BWD PW/LSP | <--------------------------- o | 
BN a lc a a rea V 
| MEP1’ MIP1’ MEP 2’ 
(S1) <============> 
(S2)< > 


Figure 2: Example of OAM Relying on Per-Node MIPs and MEPs 


To illustrate the difference between these two modes of operation, we 
use fault detection as an example. Consider the case where the 
client traffic between CE1 and CE2 experiences a fault. Also assume 
that an on-demand CV test between PE1 and PE2 was successful. The 
scenario in Figure 2 therefore leaves the forwarding engine (FW) of 
PE2, the out-going interface of PE2, the transmission line between 
PE2 and CE2, or CE2 itself as a potential location of the fault as 
on-demand CV can only be performed on segment S2. Note that in this 
scenario, the PWs or LSPs are to be understood as two examples (not 
one), i.e., the figures do not show the layer structure of PWs and 
LSPs. 


The per-interface model in Figure 3 allows more fine-grained OAM 
operations to be performed. At first, CV on segment S’4 and in 
addition CV on segment S’5 can help to rule out, for example, the 
forwarding engine of PE2. This is of course only a single example, 
and other OAM functions and scenarios are trivially conceivable. The 
basic message is that with the per-interface OAM model, an operator 
can configure smaller segments on a transport path to which OAM 
operations apply. This enables a more fine-grained scoping of OAM 
operations, such as fault localization and performance monitoring, 
which gives operators better information to deal with adverse 
networking conditions. 
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4. 


Customer | Operator’s Administrative | Customer 
Domain | Domain |Domain 
------- > | <---------------------------------------> | <------ 
CE1 T-PE/PE1 S-PE/P1 T-PE/PE2 CE2 
| <-------- > <-------- > <-------- > | 
+--+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 
M e d A A E a aa | 
E eda Pens ai AE A a E T A A 
+---+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +---+ 
In FW Out In FW Out In FW Out 
| | 
FWD PW/LSP | o0----------------------------------- > | 
| v a Konana FE Le kosea eS ee v | 
| MEP1 MIP1 MIP2 MIP3 MIP4 MEP2 | 
| | 
BWD PW/LSP <----------------------------------- o 
MEP1” MIP1’ MIP2’ MIP3’ MIP4’ MEP2’ 
(S’1) <======> 
(S’2)< > 
(S’'3)< > 
(S’4)< > 
(S’5)< > 


Figure 3: Example of OAM Relying on Per-Interface MIPs and MEPs 
Requirements and Design Considerations for Internal-MIP Addressing 


OAM messages for transit points of PWs or LSPs are delivered using 
the expiration of the TTL field in the top LSE of the MPLS packet 
header. OAM messages for the end points of PWs and LSPs are simply 
delivered as normal. These messages are distinguished from other 
(data) packets so that they can be processed as OAM. In LSPs, the 
mechanism used is the presence of the GAL in the LSE under the top 
LSE [RFC5586]. In PWs, the mechanism used is the presence of the PW 
Associated Channel Header [RFC4385] or the presence of a GAL 
[RFC6423]. In addition, two sets of identifiers exist that can be 
used to address MIPs, which are defined in [RFC6370] and [RFC6923] 


Any solution for sending OAM messages to the in- and out-MIPs must 
fit within these existing models of handling OAM. 


Additionally, many MPLS-TP nodes are implemented in a way that all 
queuing and the forwarding function are performed at the incoming 
interface. The abstract functional representation of such a node is 
shown in Figure 4. As shown in the figure, the outgoing interfaces 
are minimal and for this reason it may not be possible to include 
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MIP functions on those interfaces. This is the case for existing 
deployed implementations in particular. 


Any solution that attempts to send OAM messages to the outgoing 
interface of an MPLS-TP node must not cause any problems when such 
implementations are present (such as leaking OAM packets with a TTL 
of 0). 


MIP | 
[| oa | | 
----- >-| In | Fw | |-->-Out-|->--- 
| i/f£ ---- | i/f | 


Figure 4: Abstract Functional Representation of 
Some Existing MPLS-TP Nodes 


OAM must operate on MPLS-TP nodes that are branch points on point-to- 
multipoint (P2MP) trees. This means that it must be possible to 
target individual outgoing MIPs as well as all outgoing MIPs in the 
abstract functional representation shown in Figure 5, and to handle 
the P2MP node implementations as shown in Figure 6 without causing 
problems. 


Figure 5: Abstract Functional Representation of an 
MPLS-TP Node Supporting P2MP 
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| | i/f | 
| | | | 
| MIP: amcm bh A | 
| | [= | 
----- >-| In | Fw | |--->-Out-|->---- 
i/f | | | i/f 
---- |] 
| | | | 
|------------ | | 
| | | 


Figure 6: Abstract Functional Representation of 
Some Existing MPLS-TP Nodes Supporting P2MP 


In summary, the solution for OAM message delivery must behave as 
follows: 


o Delivery of OAM messages to the correct MPLS-TP node. 


o Delivery of OAM instructions to the correct MIP within an MPLS-TP 
node. 


o Forwarding of OAM packets exactly as data packets. 


o Packet inspection at the incoming and outgoing interfaces must be 
minimized. 


The first and second bullet points are obvious. However, the third 
bullet point is also vital. To illustrate the importance, a rejected 
solution is depicted in Figure 7. In the figure, all data and non- 
local OAM is handled as normal. Local OAM is intercepted at the 
incoming interface and delivered to the MIP at the incoming 
interface. If the OAM is intended for the incoming MIP, it is 
handled there with no issue. If the OAM is intended for the outgoing 
MIP, it is forwarded to that MIP using some internal messaging system 
that is implementation specific. 
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local OAM ----- >-| MIP | ----- >------ | MIP | 
data =====>=| In |=>=| Fw |=>=| Out |=>==== data 
non-local OAM 77777 SmI azi Pee | |~>7| i/£ |7>7777 non-local OAM 


Figure 7: OAM Control Message Delivery Bypassing 
the Forwarding Engine 


This solution is fully functional for the incoming MIP. It also 
supports control of data loopback for the outgoing MIP and can 
adequately perform some OAM features such as interface identity 
reporting at the outgoing MIP. 


However, because the OAM message is not forwarded through the 
forwarding engine, this solution cannot correctly perform OAM 
loopback, connectivity verification, LSP tracing, or performance 
measurement. 


The last bullet point is also an important requirement for any 
solution to the internal-MIP addressing problem. Since OAM packets 
that target an out-MIP need to be sent through the forwarding engine 
and treated exactly as regular data packets, the determination of 
whether to forward the packet or process it at the incoming MIP needs 
to be fast; therefore, the processing overhead must be kept to a 
minimum. In addition, there are a few OAM procedures that operate at 
line rate such as OAM loopback. This adds to the requirement of 
minimal processing overhead for both the in-MIP and out-MIP. 


Most of the above superficially appears to be an implementation 
matter local to an individual node; however, the format of the 
message needs to be standardized so that: 


o A MEP can correctly target the outgoing MIP of a specific MPLS-TP 
node. 


o A node can correctly filter out any OAM messages that were 
intended for its upstream neighbor’s outgoing MIP, but which were 
not handled there because the upstream neighbor is an 
implementation as shown in Figures 4 and 6. 


Note that the last bullet point describes a safety net in case OAM 
messages leak beyond their intended scope, but implementations should 
take care that messages do not leak so that the safety net does not 
need to be used. 
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3% 


7. 


7; 


Security Considerations 


OAM security is discussed in [RFC6371] and security aspects specific 
to MPLS-TP in general are outlined in [RFC6941]. 


OAM can provide useful information for detecting and tracing security 
attacks. 


OAM can also be used to illicitly gather information or for denial- 
of-service attacks and other types of attack. Implementations 
therefore are required to offer security mechanisms for OAM. 
Deployments are therefore strongly advised to follow the security 
advice provided in RFCs 6371 and 6941. 


Mixing of per-node and per-interface OAM on a single node is not 
advised as OAM message leakage could be the result. 
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